Thomas Vandahl wrote:
> Now, shall we release JCS as it is published there?
>
> [ ] +1 Yes, JCS 1.3 should be released
> [ ] 0 I do not care
> [ ] -1 No (give reasons)

Voting has closed. Here are the results:

+1 votes:
Hanson Char <hanson.char [at] gmail.com>
Thomas Vandahl <tv [at] apache.org>
* Henning Schmiedehausen <hps [at] intermeta.de>
* Aaron Smuts <asmuts [at] yahoo.com>
* Scott Eade <seade [at] backstagetech.com.au>
Rony G. Flatscher <Rony.Flatscher [at] wu-wien.ac.at>

0 votes:
none

-1 votes:
* sebbaz [at] gmail.com

(* denotes binding votes of PMC members)

I could not find any information about whether Rony Flatscher is a
member of the PMC, so would someone with the necessary insight please
decide if this vote passed or not.


Bye, Thomas.

Hi Thomas,

> I could not find any information about whether Rony Flatscher is a
> member of the PMC

In the committers-only SVN module is a file board/committee-info.txt
which lists the PMCs of all Apache projects. It's (supposed to be ;-)
the authoritative source. Rony Flatscher is listed there as PMC member.

I'm not sure myself how Sebastian's -1 will be weighed here. I would
have expected that the NOTICE and LICENSE files get fixed and he
changes his vote. As by his last mail on the topic, the content in
SVN did not get fixed. If you changed the release files manually, you
should commit those changes to SVN and give Sebastian some time to
change his vote.

Btw, he asked on legal-discuss about the correct usage of these
files, but I see little point in delaying the release until that
question has been answered.

cheers,
Roland

Hi Roland,

Roland Weber wrote:
> Hi Thomas,
>
>> I could not find any information about whether Rony Flatscher is a
>> member of the PMC
>
> In the committers-only SVN module is a file board/committee-info.txt
> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
> the authoritative source. Rony Flatscher is listed there as PMC member.

I came across some commit message regarding asf-authorization which
contained a list of members of the jakarta-pmc group and he was not
listed there. So I was unsure.

> I'm not sure myself how Sebastian's -1 will be weighed here. I would
> have expected that the NOTICE and LICENSE files get fixed and he
> changes his vote. As by his last mail on the topic, the content in
> SVN did not get fixed. If you changed the release files manually, you
> should commit those changes to SVN and give Sebastian some time to
> change his vote.

We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
SVN. This is at least what I understood the release-then-vote-policy
means. I have committed the latest changes and moved the tag, however.

If Rony is a PMC member we have a result of 3 +1 votes, which should be
sufficient. However its up to the PMC to decide this.

Bye, Thomas.

Rony is a PMC member.. However the -1 of Sebb (which is binding and blocking) is still there (unless
I missed his +1)..
Added Rony to the jakarta-pmc authorization file (thanx for spotting this)..

Mvgr,
Martin

Thomas Vandahl wrote:
> Hi Roland,
>
> Roland Weber wrote:
>> Hi Thomas,
>>
>>> I could not find any information about whether Rony Flatscher is a
>>> member of the PMC
>> In the committers-only SVN module is a file board/committee-info.txt
>> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
>> the authoritative source. Rony Flatscher is listed there as PMC member.
>
> I came across some commit message regarding asf-authorization which
> contained a list of members of the jakarta-pmc group and he was not
> listed there. So I was unsure.
>
>> I'm not sure myself how Sebastian's -1 will be weighed here. I would
>> have expected that the NOTICE and LICENSE files get fixed and he
>> changes his vote. As by his last mail on the topic, the content in
>> SVN did not get fixed. If you changed the release files manually, you
>> should commit those changes to SVN and give Sebastian some time to
>> change his vote.
>
> We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> SVN. This is at least what I understood the release-then-vote-policy
> means. I have committed the latest changes and moved the tag, however.
>
> If Rony is a PMC member we have a result of 3 +1 votes, which should be
> sufficient. However its up to the PMC to decide this.
>
> Bye, Thomas.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>
>

------=_Part_31890_26278671.1180903633175
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Martin,

Actually, that's not true. Releases cannot be vetoed by a -1. See
http://www.apache.org/foundation/voting.html

If there's a majority approval and at least 3 +1 PMC votes, than it's up to
the release manager to decide whether or not to release. He can decide to
table the vote based on feedback, if so desired. (We had this issue in the
release of Velocity 1.5).

WILL



On 6/3/07, Martin van den Bemt <mllist [at] mvdb.net> wrote:
> Rony is a PMC member.. However the -1 of Sebb (which is binding and
blocking) is still there (unless
> I missed his +1)..
> Added Rony to the jakarta-pmc authorization file (thanx for spotting
this)..
>
> Mvgr,
> Martin
>
> Thomas Vandahl wrote:
> > Hi Roland,
> >
> > Roland Weber wrote:
> >> Hi Thomas,
> >>
> >>> I could not find any information about whether Rony Flatscher is a
> >>> member of the PMC
> >> In the committers-only SVN module is a file board/committee-info.txt
> >> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
> >> the authoritative source. Rony Flatscher is listed there as PMC member.
> >
> > I came across some commit message regarding asf-authorization which
> > contained a list of members of the jakarta-pmc group and he was not
> > listed there. So I was unsure.
> >
> >> I'm not sure myself how Sebastian's -1 will be weighed here. I would
> >> have expected that the NOTICE and LICENSE files get fixed and he
> >> changes his vote. As by his last mail on the topic, the content in
> >> SVN did not get fixed. If you changed the release files manually, you
> >> should commit those changes to SVN and give Sebastian some time to
> >> change his vote.
> >
> > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> > SVN. This is at least what I understood the release-then-vote-policy
> > means. I have committed the latest changes and moved the tag, however.
> >
> > If Rony is a PMC member we have a result of 3 +1 votes, which should be
> > sufficient. However its up to the PMC to decide this.
> >
> > Bye, Thomas.
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> > For additional commands, e-mail: general-help [at] jakarta.apache.org
> >
> >
> >
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>



--
Forio Business Simulations

Will Glass-Husain
wglass [at] forio.com
www.forio.com

------=_Part_31890_26278671.1180903633175--

Agreed. though that page probably needs a bit of a reality check.. The problem is when someone does
a -1 with reasoning, people tend to stop voting until that vote is switched to a +1 and if that vote
is switched to a +1 and there are enough votes, people that stopped voting will keep silent.

Hope I make sense :)

Mvgr,
Martin

Will Glass-Husain wrote:
> Martin,
>
> Actually, that's not true. Releases cannot be vetoed by a -1. See
> http://www.apache.org/foundation/voting.html
>
> If there's a majority approval and at least 3 +1 PMC votes, than it's up to
> the release manager to decide whether or not to release. He can decide to
> table the vote based on feedback, if so desired. (We had this issue in the
> release of Velocity 1.5).
>
> WILL
>
>
>
> On 6/3/07, Martin van den Bemt <mllist [at] mvdb.net> wrote:
>> Rony is a PMC member.. However the -1 of Sebb (which is binding and
> blocking) is still there (unless
>> I missed his +1)..
>> Added Rony to the jakarta-pmc authorization file (thanx for spotting
> this)..
>>
>> Mvgr,
>> Martin
>>
>> Thomas Vandahl wrote:
>> > Hi Roland,
>> >
>> > Roland Weber wrote:
>> >> Hi Thomas,
>> >>
>> >>> I could not find any information about whether Rony Flatscher is a
>> >>> member of the PMC
>> >> In the committers-only SVN module is a file board/committee-info.txt
>> >> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
>> >> the authoritative source. Rony Flatscher is listed there as PMC
>> member.
>> >
>> > I came across some commit message regarding asf-authorization which
>> > contained a list of members of the jakarta-pmc group and he was not
>> > listed there. So I was unsure.
>> >
>> >> I'm not sure myself how Sebastian's -1 will be weighed here. I would
>> >> have expected that the NOTICE and LICENSE files get fixed and he
>> >> changes his vote. As by his last mail on the topic, the content in
>> >> SVN did not get fixed. If you changed the release files manually, you
>> >> should commit those changes to SVN and give Sebastian some time to
>> >> change his vote.
>> >
>> > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
>> > SVN. This is at least what I understood the release-then-vote-policy
>> > means. I have committed the latest changes and moved the tag, however.
>> >
>> > If Rony is a PMC member we have a result of 3 +1 votes, which should be
>> > sufficient. However its up to the PMC to decide this.
>> >
>> > Bye, Thomas.
>> >
>> > ------------------------------------------------------------ ---------
>> > To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
>> > For additional commands, e-mail: general-help [at] jakarta.apache.org
>> >
>> >
>> >
>>
>> ------------------------------------------------------------ ---------
>> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
>> For additional commands, e-mail: general-help [at] jakarta.apache.org
>>
>>
>
>
>

On 6/3/07, Martin van den Bemt <mllist [at] mvdb.net> wrote:
> Agreed. though that page probably needs a bit of a reality check.. The problem is when someone does
> a -1 with reasoning, people tend to stop voting until that vote is switched to a +1 and if that vote
> is switched to a +1 and there are enough votes, people that stopped voting will keep silent.
>
> Hope I make sense :)
>
<snip/>

Concretely, Thomas / Will -- In this particular scenario, I wouldn't
release if I were the RM until I was able to work this out with sebb.
YMMV.

-Rahul


> Mvgr,
> Martin
>
> Will Glass-Husain wrote:
> > Martin,
> >
> > Actually, that's not true. Releases cannot be vetoed by a -1. See
> > http://www.apache.org/foundation/voting.html
> >
> > If there's a majority approval and at least 3 +1 PMC votes, than it's up to
> > the release manager to decide whether or not to release. He can decide to
> > table the vote based on feedback, if so desired. (We had this issue in the
> > release of Velocity 1.5).
> >
> > WILL
> >
> >
> >
> > On 6/3/07, Martin van den Bemt <mllist [at] mvdb.net> wrote:
> >> Rony is a PMC member.. However the -1 of Sebb (which is binding and
> > blocking) is still there (unless
> >> I missed his +1)..
> >> Added Rony to the jakarta-pmc authorization file (thanx for spotting
> > this)..
> >>
> >> Mvgr,
> >> Martin
> >>
> >> Thomas Vandahl wrote:
> >> > Hi Roland,
> >> >
> >> > Roland Weber wrote:
> >> >> Hi Thomas,
> >> >>
> >> >>> I could not find any information about whether Rony Flatscher is a
> >> >>> member of the PMC
> >> >> In the committers-only SVN module is a file board/committee-info.txt
> >> >> which lists the PMCs of all Apache projects. It's (supposed to be ;-)
> >> >> the authoritative source. Rony Flatscher is listed there as PMC
> >> member.
> >> >
> >> > I came across some commit message regarding asf-authorization which
> >> > contained a list of members of the jakarta-pmc group and he was not
> >> > listed there. So I was unsure.
> >> >
> >> >> I'm not sure myself how Sebastian's -1 will be weighed here. I would
> >> >> have expected that the NOTICE and LICENSE files get fixed and he
> >> >> changes his vote. As by his last mail on the topic, the content in
> >> >> SVN did not get fixed. If you changed the release files manually, you
> >> >> should commit those changes to SVN and give Sebastian some time to
> >> >> change his vote.
> >> >
> >> > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> >> > SVN. This is at least what I understood the release-then-vote-policy
> >> > means. I have committed the latest changes and moved the tag, however.
> >> >
> >> > If Rony is a PMC member we have a result of 3 +1 votes, which should be
> >> > sufficient. However its up to the PMC to decide this.
> >> >
> >> > Bye, Thomas.
> >> >

Hi Thomas,

>> If you changed the release files manually, you
>> should commit those changes to SVN and give Sebastian some time to
>> change his vote.
>
> We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> SVN. This is at least what I understood the release-then-vote-policy
> means.

The point of a SVN branch is to have an archived version of the
exact files that go into the release. If you have to change a
release after creating the branch, you should update the branch
and re-build the release from scratch. This is the best way to
make sure that releases can be reproduced.

cheers,
Roland

On 06/06/07, Roland Weber <ossfwot [at] dubioso.net> wrote:
> Hi Thomas,
>
> >> If you changed the release files manually, you
> >> should commit those changes to SVN and give Sebastian some time to
> >> change his vote.
> >
> > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> > SVN. This is at least what I understood the release-then-vote-policy
> > means.
>
> The point of a SVN branch is to have an archived version of the
> exact files that go into the release. If you have to change a
> release after creating the branch, you should update the branch
> and re-build the release from scratch. This is the best way to
> make sure that releases can be reproduced.

s/branch/tag/g surely?

S///

sebb wrote:
> s/branch/tag/g surely?

Eh... CVS tag = SVN branch? Whatever, the things that are
not trunk and from which you can get a named historic version
(=revision?) of what used to be in trunk :-)

It's called "level" in CMVC, and I just don't want to spend
my time on learning a separate vocabulary for every source
repository system out there :-(

cheers,
Roland

On 06/06/07, Roland Weber <ossfwot [at] dubioso.net> wrote:
> sebb wrote:
> > s/branch/tag/g surely?
>
> Eh... CVS tag = SVN branch? Whatever, the things that are

No, CVS tag = SVN tag

> not trunk and from which you can get a named historic version
> (=revision?) of what used to be in trunk :-)

In SVN, there is no distinction between tags and branches (or indeed trunk).
They are all just directory names.

But the convention is to use

trunk

for mainline code;

branch/branch-name

for any parallel developments (which may one day get merged into trunk); and

tags/tagname

to identify a snapshot which does not change.

SVN does not prevent anyone from updating any of the directories,
whereas as I recall, CVS tags were not as easy to update once created.

So a release can be developed in a branch or the trunk; before the
release is finally built the current files should be copied to a
subdirectory of tags.

The tags subdirectory should not be updated once created.


> It's called "level" in CMVC, and I just don't want to spend
> my time on learning a separate vocabulary for every source
> repository system out there :-(
>
> cheers,
> Roland
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
>

Hi Sebastian,

> So a release can be developed in a branch or the trunk; before the
> release is finally built the current files should be copied to a
> subdirectory of tags.
>
> The tags subdirectory should not be updated once created.

The branch was the correct term. You copy trunk into a branch
in case you need to update something. Once the release is done
you cut off the branch and stick a tag to it :-)

cheers,
Roland

This is my personal model for this stuff. YMMV


---- trunk -------+---- main development -----------
|
release branch branches/JCS_1_3
|
+ --- tag tags/JCS_1_3_RC1
|
+ --- tag tags/JCS_1_3_RC2
|
+ --- tag tags/JCS_1_3
|
+ --- tag tags/JCS_1_3_1


you release *from* a release branch *on* a release tag.

Best regards
Henning




On Wed, 2007-06-06 at 18:41 +0100, sebb wrote:
> On 06/06/07, Roland Weber <ossfwot [at] dubioso.net> wrote:
> > Hi Thomas,
> >
> > >> If you changed the release files manually, you
> > >> should commit those changes to SVN and give Sebastian some time to
> > >> change his vote.
> > >
> > > We were voting on the artifacts on people.apache.org/~tv/jcs/, not on
> > > SVN. This is at least what I understood the release-then-vote-policy
> > > means.
> >
> > The point of a SVN branch is to have an archived version of the
> > exact files that go into the release. If you have to change a
> > release after creating the branch, you should update the branch
> > and re-build the release from scratch. This is the best way to
> > make sure that releases can be reproduced.
>
> s/branch/tag/g surely?
>
> S///
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe [at] jakarta.apache.org
> For additional commands, e-mail: general-help [at] jakarta.apache.org
>
--
Henning P. Schmiedehausen -- hps [at] intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

On Wed, 2007-06-06 at 19:13 +0100, sebb wrote:
> On 06/06/07, Roland Weber <ossfwot [at] dubioso.net> wrote:
> > sebb wrote:
> > > s/branch/tag/g surely?
> >
> > Eh... CVS tag = SVN branch? Whatever, the things that are
>
> No, CVS tag = SVN tag

No. SVN tag == SVN branch == shallow directory copy.

There is just a convention in SVN to distinguish branches and tags. Both
are the same thing, just in different places ( /branches and /tags).

A CVS tag is something totally different. A CVS tag is a named set of
different file revisions and basically a kludge if you do not have a
repository-wide atomic revision number. Which subversion has.

Best regards
Henning

--
Henning P. Schmiedehausen -- hps [at] intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

On 07/06/07, Henning Schmiedehausen <hps [at] intermeta.de> wrote:
> On Wed, 2007-06-06 at 19:13 +0100, sebb wrote:
> > On 06/06/07, Roland Weber <ossfwot [at] dubioso.net> wrote:
> > > sebb wrote:
> > > > s/branch/tag/g surely?
> > >
> > > Eh... CVS tag = SVN branch? Whatever, the things that are
> >
> > No, CVS tag = SVN tag
>
> No. SVN tag == SVN branch == shallow directory copy.

Depends on your meaning of "shallow" - changing a file in the original
does not change the file in the copy.

> There is just a convention in SVN to distinguish branches and tags. Both
> are the same thing, just in different places ( /branches and /tags).

Yes, I think that's what I said.

> A CVS tag is something totally different. A CVS tag is a named set of
> different file revisions and basically a kludge if you do not have a
> repository-wide atomic revision number. Which subversion has.

What I meant was that the /tags directory is conventionally used in
SVN where one would use tags in CVS.

Rather than using the revision number for building/representing a
release, a tag is created, and then never updated. The tag tree thus
contains a specific revision of the the database, and is a way of
giving the revision a name.

As far as I can see, SVN tags are a convenience - one could just
document which revision constitutes the release, and use that to to do
the build or retrieve the files.

S///